home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL96.LZH / t0128 / text0053.txt < prev   
Encoding:
Text File  |  1996-03-07  |  4.7 KB  |  110 lines
  1.  
  2.  
  3.  
  4.  DM> While I have no problem with the sources being badly (or not at
  5.  DM> all) commented (I do the same myself far too often), not having the
  6.  DM> them available in _any_ form is of course totally unacceptable.
  7.  
  8. You have to remember that no useful information on Doom's texturemapping 
  9. techniques has been made available to me, and I have been unable to find
  10. this information myself in any of the documentation supplied by friends or
  11. found in various PC literature. My only alternative is to employ techniques
  12. I have developed on my own - for other projects - in order to get Bad Mood
  13. into a state where people can see what kind of potential is available here
  14. through the Falcon.
  15.  
  16.  
  17. The techniques involved are my own work, and do not belong in the public 
  18. domain in any form. I make my living from the techniques I develop & the
  19. programs which use them and I see no reason for handing them out to all and
  20. sundry. I believe that you have taken this point of view for certain
  21. efforts of your own and the argument is no less valid from my own
  22. standpoint.
  23.  
  24.  
  25. If somebody can find a useful description of the formulae and approach 
  26. employed by Doom to deal with this problem, then I will be happy to replace
  27. my code with a DSP version of those routines. Until then I'm hanging onto
  28. the source.
  29.  
  30.  
  31. Aside from the above (and assuming I do make the DSP sources available), I 
  32. don't believe it is wise to have others modify the code. It's not like a
  33. nice clear 'c' or basic program with nice tidy functions - it consists of
  34. broken down mathematical formulae and very complicated linked list
  35. structures - all in DSP assembly with up to 3 separate threads per line.
  36. Changing these an any way without a near complete understanding of what's
  37. going on in there leads to an abrupt loss of Falcon doom. It would be
  38. possible to rewrite large chunks of the code if you were very careful, but
  39. it would be easier to start from scratch.
  40.  
  41.  
  42. What I don't want to see is people meddling with it and then complaining 
  43. about 'bits missing' on the display or 'occasional crashing' and so on.
  44. What happens here is I get loads of E-mail to the effect that my code has
  45. lots of bugs and that I need to fix them soon. In other words, as soon as
  46. people start editing the DSP code, I am no longer responsible for what goes
  47. wrong - and refuse to maintain, repair or upgrade it afterwards.
  48.  
  49.  
  50.  DM> That may be, but having only one person in the world capable of
  51.  DM> improving/ extending the code or fixing bugs is a _lot_ worse.
  52.  
  53. I'm afraid that depends on what the code does. With this particular one, 
  54. there's a much greater chance that it will get worse rather than get
  55. better. I already find it difficult enough to maintain myself, and I'm just
  56. astonished I got certain bits working at all.
  57.  
  58.  
  59. This is not what's keeping me from releasing the sources, but it does tend 
  60. to put me off the idea.
  61.  
  62.  
  63.  DM> Apart from that, it goes against the whole original idea of the
  64.  DM> project: to create something that could be worked on by anyone,
  65.  DM> anywhere, at any time.
  66.  
  67. This I completely agree with, but I'm not prepared to release key parts of 
  68. that code onto the PD. If I can replace them with the original methods,
  69. then I'll be happy to release the DSP sources. Ok?
  70.  
  71.  
  72.  DM> Comments can be added over time by people who examine the code.
  73.  
  74. And I hate to think what those comments might be... :)
  75.  
  76.  DM> Doing it to the original sources will be a lot easier than trying
  77.  DM> to do the same with a straight disassembly, which _will_ be supplied
  78.  DM> if the sources are not.
  79.  
  80. Threatening to disassemble something against the programmer's will is 
  81. definitely not the answer. The prospect of this alone would be enough to
  82. get most people really upset, most probably yourself included. :)
  83.  
  84.  
  85. Besides, do you really think that I would supply sensitive data in a form 
  86. from which it could easily be disassembled? And it's worth noting that
  87. fragmented assembly language versions of mathematical formulae which
  88. include everything from scalar relationships to calculus isn't exactly
  89. going to jump off the page, begging for a description. No - the only useful
  90. DSP sources which will become available are those which will reflect the
  91. true Doom equations and methods, which I do not yet have.
  92.  
  93.  
  94. I have heard that the DEE team are prepared to share some of their secrets 
  95. with us, maybe even some source. This would be a great place to start if we
  96. are to find these methods and implement them quickly.
  97.  
  98.  
  99. Doug.
  100.  
  101. ┌───────────────────────────────────────────────────────────────────────┐
  102. | Black Scorpion Software / Falcon040 ~ 4MbSRam ~ 16MbFRam ~ Expose ~:) |
  103. ├───────────────────────────────────────────────────────────────────────┤
  104. | Doug Little ~ Neil Stewart ~ Dave Murphy ~ Nick Hesketh ~ Dave Encill |
  105. └───────────────────────────────────────────────────────────────────────┘
  106.  
  107. --
  108.  
  109.  
  110.